\section{The Proposed Work}
\label{sec:ProposedWork}

In this Section, we present our approach for testing \textsc{SA}s. Figure~\ref{fig:Overview} is an overview of our proposed work, and helps in understanding our contribution.

The first step of our work is to design a Test Model using architectural information. We use UML Sequence Diagram for our test model. A design method is presented in next section. Test Model is used as an input for Abtract Test Case extraction.The abstract test cases are extracted through control flow and partial data flow analysis. We further discuss the approach in detail in sub sections. 

\begin{figure}[t]
\centering
\includegraphics[scale=0.45]{fig/hh.pdf}
\caption{Overview of the Approach}
\label{fig:Overview}

%\vspace{-0.6cm}
\end{figure}

\subsection{Test Model for Software Architecture}
\label{sec:TMSA}

A Test Model is a view of the System Under Test (\textsc{SUT}) and the Test Environment (\textsc{TE}), for testing purposes. In particular for \textsc{SA}s, the details of the architectural specifications are abstracted away to keep a limited set of details that are required for modeling test requirements. However, the language used for the design of the Test Model should be expressive enough to capture model at different levels of abstractions. In order to correctly model these interactions, we need a language with a well-defined syntax and semantics, as well as tool support for performing the necessary management operations of such models. We are also concerned to keep track of \textsc{SA} interfaces and their connections to be able to test the communications between the whole system's components.

% for the purpose of testing. In a test model, the detailed architectural  specifications are abstracted away to get limitted details required for modeling test requirements. The modeling language for the design of test model should be expressive enough to model test relevant detail at different abstraction levels. Software architectural information in the form of interfaces and their connections is utilized to test communication of the whole system. To model the interaction of architectural components, we need a language with well defined syntax, semantics and tool support. We chose to model the interactions among architectural components using UML  Sequence Diagram (SD). 


\textsc{Uml} Sequence Diagrams (\textsc{Sd}s) is a good candidate: based on events interactions, it provides the correct abstraction level for capturing \textsc{SA}s interactions, using message passing. The semantics of an interaction in \textsc{SD} is  described as a "pair of traces" \cite {Superstructure}, which can be either valid or invalid. Generally for modeling software systems, only valid traces are modeled, but in order to capture test-specific behaviour, we use both: invalid traces are modeled to extract unintended behaviours.
In next Sections we discuss different components of Test Model and their mapping on \textsc{SD}.

%UML Sequence diagrams are used to model interaction of a classifier. The chosen abstraction level to represent a test model for software architecture is relatively higher to include architecrual specifications. We model the interactions within a system, through its connectable elements i.e. components. The interaction between components is shown in the form of message passing. The semantics on interaction in UML interactions are described as a 'pair of traces'. The traces can be both valid traces and invalid traces \cite {Superstructure}. For modeling software systems, generally only valid traces are modeled. In order to model test specific behavior we capture both valid traces and invalid traces. Invalid traces are modeled where there is a decision or choice in the form of pre/post conditions or assertions. We discuss the detail of methodology for test modeling of software architecture using SD.




\subsubsection{System Under Test (\textsc{Sut})}
\label{sec:SUT}

The \textsc{SUT} is a part of whole software architecture that representes the test requirements. As we aim at testing the interactions between \textsc{SA} components for some specific behaviour, we only retain those components that take part in the completion of the behaviour to be tested. Such components are called Component Under Test (\textsc{CUT}s). Each \textsc{CUT} is represented by a lifeline in a \textsc{SD}. The identification of such \textsc{CUT} within the whole system already reduces the size of a Test Model.

%, it includes only those components and connections that are test specific. The \textsc{Sut} is modeled with respect to the test requirements. In this work, our aim is to model interactions in \textsc{Sa} for some specific behavior. The \textsc{Sut} is comprised of those components of software architecture that take part in the completion of behaviour to be tested. Such components are called Component Under Test (CUT). Each CUT in a SUT is represented by a lifeline on SD.Identifying CUT already reduces the size of a test model and includes only a subset of the whole architecture.

Each \textsc{CUT} is in turn composed of its interface. The interface of a component may have a number of attached ports. We only include the components' ports that are needed for the purpose of testing. For example for our running example, if the requirement is to test the \textsf{withdraw} operation, the Test Model in Fig. \ref{fig:Withdraw} shows which behaviours are invoked in the \textsf{Manager} Component to complete the \textsf{withdraw} operation requested from the Bank. All other ports and operations define in Table 1 for Manager component are not involved in accomplishment of withdraw behaviour, so they are discarded. We propose only one light weight extension to the \textsc{SD} with stereotypes \texttt{<<provide>>} and \texttt{<<require>>} to be able to distinguish between both kinds of operations.

Bindings are included only if they are related to the ports and components previously selected. In the \textsc{SD}, they appear as execution specifications, with the corresponding operations as a message on top of it. 

%For instance in Figure \ref{}, we have shown that the CUT Manager invokes only those behavior that are needed to complete withdraw from the bank. All other ports and operations attached to Component Manager are not included in the test model. The operations with ports are modelled as messages between different CUTs. We have included a light weight extension to SD, two stereotypes called require and provide to represent two types of operations in software architecture.

%The bindings between different ports in software architecture are also included in test model. We have included only those bindings that link the ports in SUT. All other bindings are not part of SUT. The bindings are mapped in sequence diagram as occurrrence specifications. Binding connect send occurence with recieve occurence for a particular message.

Table \ref{table:map} summarises the mappings between the \textsc{SAL} constructs and the \textsc{SD} syntax.


\subsubsection{Test Environment (\textsc{Te})}
\label{sec:TE}

The \textsc{TE} is composed of an \emph{Observer} and a \emph{Tester}. An Observer is a system external to the \textsc{SUT}, but it is linked to the \textsc{SUT} and the Tester. Its function is to record and keep traces of all communications between the involved \textsc{CUT}s, and the communications between the \textsc{CUT}s and the Tester. The information recorded by the Observer is used for extracting test verdicts during the execution phase, and we plan to further use it in other testing activities, especially for regression testing and impact analysis. The actual implementation of the Observer and Tester is beyond the scope of this paper, and highly depends on the underlying software implementation, but our approach allows the use of different observers for the case of distributed systems testing.

%We propose a test envoirnment for software architecture based testing, it is composed of an Observer and a Tester components. The Observer is a system that keeps track of all the communication between different CUTs. The observer component is linked with all the components in test model i.e. SUT and Tester, it records communications and keeps a  trace. We model Observer component in order to keep the trace information for communication between tester and CUT. This trace information is important for extracting test verdicts in the execution phase. The trace information can also be used in other testing activities such as regression testing and impact analysis. The observer component is part of the test environment and is kept on the same system as the tester.  The implementation of observer system depends on the underlying implementation of the software architecture. Moreover in distributed systems, we may have multiple observers lying on different machines. The implementation of Observer is out of scope of this paper.

\begin{figure}[t]
\centering
\includegraphics[scale=0.45]{fig/TestModel01.pdf}
\caption{Test Model-Interaction between Observer,Tester and SUT}
\label{fig:TestBehaviour}
\end{figure}

The Tester interacts with \textsc{CUT}s , and provides possible inputs for testing. It can be either a human operator, or an automated system. It can be paired with the Observer and kept totally independent, and is linked with the \textsc{SUT} but cannot see the internal communication between components.

%The other component of the test envoirnment is a Tester, which is either a human or a system that initiates the SUT with test inputs. A Tester is the one that is interestec in testing of the system. A Tester component can be a part of Observer component or it can be an independent component. The Tester is linked with SUT and can not see the internal communication of the somponents. 

Figure \ref{fig:TestBehaviour} presents the high-level interaction between the \texttt{SUT} and the \textsc{TE}. The infrastructure is left open: an \textsc{SUT} can operate several \textsc{CUT}s; and several instances of an \textsc{SUT} can be involved at the same time. The Tester communicates directly with the \textsc{SUT} by sending inputs for testing; the Observer keeps track of any communication in the infrastructure: as depicted in Fig. \ref{fig:TestBehaviour}, every transaction generates duplicated messages, one addressed to the requester, and the other one for the Observer.

%There can be many instances of SUT, as there can be many CUTs interacting in a SUT. The tester directly communicates with SUT and sends input for testing. The Observer is basically linked with all the components and whenever some communication takes place, it sends the information to the observer.For instance in this case, every transaction generates a duplicate message, one for the requester and the other for the Observer component.
%
%\begin{figure}[ht!]
%\centering
%\includegraphics[scale=0.75]{}
%\caption{Test Environment and System Under Test}
%\label{testsut}
%\end{figure}

\subsubsection{Error Messages}
\label{sec:EM}

Modeling of Error Messages is important in any Test Model as they are significant in identifying unintended behaviours. We have mapped the pre/post conditions of operations to choice/Alt frams in \texttt{SD}. The invalid execution of the pre/post conditions is annotated with an Error Messages. Similary assertions are shown on \texttt{SD} as state invariants and their invalid trace is added to specifify abnormal execution. 


\subsection{Test Model for\textsf{withdraw} behaviour in the Bank Application }
\label{sec:TestingBank}


Figure \ref{fig:Withdraw} is the Test Model of Behavior withdraw of the Bank Application. In Figure \ref{fig:Withdraw} the interaction of Tester component is modeled with \textsc{CUT}s. Observer component is eliminated in this diagram for simplicity reasons.The \textsc{CUT}s are Manager , Saving and Client. Tester initiates the Manager components by sending a message, Manager in turn communicates with other component. It is to be considered that whenever there is a transaction the reply message is duplicated: one for the requester and the other for the Observe of the system. In the Test Model the alt frame represents the pre condition attached with withdraw operation. The Error Messages are presented in else part in these frames.

\begin{table}[!htp]
\renewcommand{\arraystretch}{1.3}
	\centering
	\begin{scriptsize}
		\begin{tabular}[htp!]{|c|c|}
		\hline
		\textbf{Saf-Archie Construct} & \textbf{Sequence Diagram construct} \\
		\hline
		\hline
		Component  & LifeLine \\
		\hline
		Port & Occurrence Specification 
		\\
		\hline
	Operation & Message\\
		\hline
		Binding & Occurrence Specification\\
		\hline
		Pre/Post Conditions & Alt/Option Frames\\
		\hline
	\end{tabular}
	\end{scriptsize}
	\caption{Mapping from Saf-Archie to SD} 
	\label{table:map}
\end{table}


The \textsc{SD} based Test Model is further used for Abstract Test case (ATC) generation. \textsc{ATC}s can not be extracted directly from Test Model due to presence of asynchronous messages this causes the problem of paralellism. We use an intermediate model to extract test cases. ATCs generation is explained in the next section.

\begin{figure}[t]
\centering
\includegraphics[scale=0.45]{fig/TestModel22.pdf}
\caption{Test Model for Withdraw behavior in Bank System}
\label{fig:Withdraw}
\end{figure}


\subsection{Generating Abstract Test Cases}

This Section discusses the generation of \textsc{ATC}s from Test Model for \textsc{SA}s. The input for this phase is the test model designed using \textsc{SD}. As shown in Figure \ref{fig:Overview}, the way forward for \textsc{ATC} generation is to perform control flow and partial data flow analysis. Control Control Flow and data flow analysis are carried out using a control flow graph \cite {S.Muchnick1997} with data flow information. The term partial is used with data flow as complete data information is missing at \textsc{SA} level. The Control Flow Analysis \textsc{CFA} and data flow analysis \textsc{DFA}\cite {S.Muchnick1997}, are well known approaches for model based testing \cite{A.Rountev2005}.

Our choice for control flow graph is UML Activity Diagram (AD). \textsc{AD} provides control nodes and objects nodes,control node is to represent control information and object node possess data information. Vahid Garousi \emph{et al.} \cite { VahidGarousi2005} have used AD for control flow analysis from SD. We are benefitting from their with some additions. The control flow modeling from \textsc{SD} Test Model is same as in Vahid Garousi \emph{et al.} \cite { VahidGarousi2005} work. The \textsc{SD} test model is mapped to an \textsc{AD}. Control Nodes are used to to represent messages of \textsc{SD} Test Model. Control nodes are linked using control flow. The problem of asynchronous messages is also handled by introducing a fork node and two control flows. One control flow shows the return of asynchronous messages and the other control flow shows the sunsequent flows in the test model. The work of Vahid Garousi \emph{et al.} \cite { VahidGarousi2005} do not discuss data flow along with \textsc{CFA}. We propose to use Object Node for return values of messages. This data in Obejct Node is utilized in data flow analysis. We have not shown Object node with every control node for simplicity, in practice it can be done for more clarity of data flows. We have used AD without any extensions that supports the use of UML case tools for the work.

Figure \ref{fig:AD} is an \textsc{AD} for test model in Figure\ref{fig:Withdraw}. The \textsc{AD} is traversed to get \textsc{ATC}s. An ATC is defined as a combination of sequence of messages and data values, from start node of AD to the final node.We have shown ATCs in Listing below. The \textsc{ATC} contain no specific data values, the choice of data values is dependent on underlying implementation.
\textsc{ATC} cover all paths in \textsc{AD} for withdraw test model. However, it is generally not required to test every paths for complete coverage. The number of \textsc{ATC} can be reduces by applying coverage criteria. The definition of coverage criteria is out of scope of this paper.

\begin{figure}[t]
\centering
\includegraphics[scale=0.9]{fig/CFG.pdf}
\caption{Activity Diagram to Represent Test Modeling Figure 4}
\label{fig:AD}
\end{figure}



{\begin{lstlisting}[language= VIA, caption=Abstract Test Cases for withdraw behavior, label=list:banking]
ATC1= 1,2,A,3
ATC2= 1,2,A,3,4,B,5,14,15
ATC3= 1,2,A,3,4,B,5,6,C,7,11,E,12,13
ATC4= 1,2,A,3,4,B,5,6,C,7,8,D,9,10
ATC5= 1,2,A,3,4,B,5,6,9,10
ATC6= 1,2,5,14
ATC7= 1,2,5,6,C,7,11,E,12,13
ATC8= 1,2,5,6,C,7,8,9,10
ATC9= 1,2,5,6,9,10
ATC10= 1,10
\label{tab:ATC}
\end{lstlisting}
}

